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REMARKS 

SECTION 101 REJECTION OF CLAIM 38 

Applicant acknowledges with appreciation the withdrawal of the section 101 rejection of 

claim 38. 

SECTION 102 REJECTIONS 

Applicant acknowledges with appreciation the Examiner's finding that Sweat^ fails to 

disclose each and every limitation of the claims, and the resulting withdrawal of all rejections 
based on section 102. 

CLAIM AMENDMENTS 

Applicant amends claims 1, 30, 31, and 38. Applicant requests reconsideration and 

withdrawal of all section 103 rejections based on the foregoing amendments and the following 
remarks. 

SECTION 103 REJECTION OF CLAIMS 1, 30, 31, AND 38 

As a threshold matter, the Office Action appears to include a typographical error. A 

subheading on page 3 of the action indicates that Claims 1, 3-6, 8, 11-32, and 36-38 are rejected 
under 35 U.S. C. 102(e) as being anticipated by Sweat. ^ However, another heading on the same 
page, and the discussions supporting the rejections of cMms 1, 30, 31, £ind 38 rely on the 
combination of Sweat and Beizer? Appliczint therefore assumes that the rejections were made 
under 35 U.S.C. 103(a). 

Sweat fails to disclose web page that includes data representing a hierarchy 

Claim 1 recites 

"making a web page available for access by a user at a first client." 

As recited in claim 1, this web page must include, as a constituent part thereof, "locally- 
stored date representing the hierarchy." 



^ U.S. Patent No. 7,062,532. 
^ U.S. Patent No. 7,062,532. 
^ U.S. Patent No. 6,240,414. 
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Applicant fully agrees that Sweat discloses "making a web page available for access by a 
user" of the PROJECTPOINT software, and that a typical web page, which is shown in Sweat 
FIG. 5, displays a hierarchy of folders. It is therefore evident that somewhere, there must exist 
data defining a hierarchy of folders. 

Where Applicant and the Office differ is where exactly this "somewhere" is. The Office's 
position is that the hierarchical data is somehow part of the web page in FIG. 5. The Office 
appears to assume that just because a hierarchy of folders is displayed on a web page, it is 
somehow inherent that the data that defines that hierarchy must actually be part of the web page. 

Sweat makes no express disclosure of where the data that defines the hierarchy of folders 
in FIG. 5 is actually stored. It is possible that this data is actudly a constituent component of the 
web page. But it is also possible, £ind more likely, that the data is stored somewhere else, such as 
on a server 106. 

In the present case, the Office has not actually shown that the data representing the 
hierarchy of folders in FIG. 5 is actually a constituent part of the web page. 

Moreover, one of ordinary skill in the art would assume that the location of the 
hierarchicEil data used in FIG. 5 is at the server, £ind not in the web page itself. The reasoning that 
would have led one of ordinary skill in the art to this inference is as follows: 

One of ordinary skill in the art would have understood that the purpose of the Sweat 
device was to allow designers working at various locations to collaborate with other. It would 

have been apparent to one of ordinary skill in the art that such collaboration would require 
designers to identify particular drawings, and that this would be made easier if all designers 
worked within a conmion hierarchy of folders for storing drawings. 

One of ordinary skill in the art would have understood the Office's assumption, which is 
that each designer has his own local hierarchy, which he can change independently of all other 
designers, as undermining the ability of Sweafs system to achieve its intended purpose. 
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Specifically, one of ordinary skill in the art would have realized that if each designer had his own 
local hierarchy, the designers would soon find it difficult to be sure that the drawings they are 
working on are the correct drawings. Thus, one of ordinary skill in the art would have regarded 
the Office's assumption concerning the operation of the PROJECTPOINT software to be 
unlikely because it would actually undermine the operation of that software by making it more 
difficult for designers to collaborate on projects. 

It is apparent therefore that Sweat lacks any express teaching of where the data defining 
the hierarchy of folders in FIG. 5 is stored. It is also apparent that such data could be stored in 
any number of places. Thus, there is no basis for assuming that the data must inherently be a 
constituent part of the web page of FIG. 5. 

A proper section 103 rejection requires that the combination of references disclose each 
and every claim limitation. In the present case. Sweat fails to disclose "making a web page 

available for access by a user at a first client" with that web page also including "locally-stored 
data representing the hierarchy." Beizer fails to remedy this deficiency in the teaching of Sweat. 
The combination of Beizer and Sweat therefore fails to disclose this limitation. Accordingly, the 
section 103 rejection based on Sweat and Beizer is improper. 

Sweat fails to disclose a web page that includes "rules defining those modifications... that 
any user is permitted to malce" 

Claim 1 also requires that the web page that is made available to users include, as a 

constituent part thereof, "rules defining those modifications to a structure of the locally- stored 
data representing the hierarchy that any user is permitted to make to the data." 

Sweat shows web pages with information about file protection. However, Sweat is silent 
on exactly where this information is kept. Nor is it necessarily the case, based on Sweafs 
disclosure, that such information is necessarily stored as a constituent part of a web page. 

Accordingly, Sweat fails to disclose the foregoing limitations for at least the reasons 
described above in connection with the hierarchical data. 
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Sweat fails to disclose '^detecting, at a server, in real-time, a modification to locally-stored 
data occurring at a second client 

Claim 1, as amended, includes the steps of 

"detecting at a server, in real-time, a modification to locally-stored data occurring at a second client; [and] 

sending a call from the first client to the server to enforce rules involving multiple users based on detecting 
the modification to locaUy-stored data that occurred at the second client, the call being sent before the 
modified data has been saved to the server[.]" 

Sweat fails to disclose a detection step as recited above in which the detection takes place 
"at a server". 

Beizer also fails to disclose "detecting, at a server, in real-time, a modification to locally- 
stored data occurring at a second client 

The ExEiminer asserts that 



Beizer et al in an analogous art teaches a method and system for automatically identifying and resolving 
data conflicts in a shared environment (see abstract) and discloses detecting in real-time a modification to 
locally-stored data occurring at a second client, (see column 6, lines 18-24) sending a call to a server based 
on detecting the modification to locally stored data occurring at the second cUent to enforce rules involving 
multiple users when modified data has not yet been saved to the server (not yet saved to the master copy) 
(see column 6, lines 30-35). " 

Beizer does not, however, disclose a detecting step as recited in claim 1. Rather Beizer describes 

a process for editing files and folders in which 

a local copy 54 is transferred from the shared storage 50 to a local storage area 56 where it is readily 
accessible and may be modified by the user. Often, the original local copy of the WorkFolder 54 is 
preserved when the WorkFolder is edited and a separate local edit copy 58 is created. When the local edited 
WorkFolder 58 is saved, it can be compared to the local original copy 54 to determine what changes were 
made by the user and also compared to the master copy 52, which may itself have been changed by a 
second user in the interim.^ 

This is consistent with the text cited by the Examiner in which 

As an example, users 1 and 2 simultaneously open the same WorkFolder. User 1 attaches a document to the 
WorkFolder and changes a status data field to "completed." User 2 simultaneously opens another document 
in the WorkFolder and, based on its contents, enters the value of several other WorkFolder fields, i.e., 
current disbursements and income. Because neither user changed the same objects in the WorkFolder, the 
changes do not conflict with each other. Therefore, the changed and added data can be merged into the 
master WorkFolder. If both users change the same data field, i.e., user 1 changes the status field to 
"complete" while user 2 changes it to "on hold", and then both try to save the updated workfolder to the 



Office action mailed June 24, 2008, pages 4-5. 
^ See e.g., Beizer col. 5, hne 46 - col. 6, Une 3. 
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network storage area, the reconciliation logic detects the conflict and invokes an attended conflict 
resolution routine wherein one or both of the user's are prompted with a hst of the conflicting changes and 
then asked to resolve, for each detected conflict, which of the conflicting values should persist in the master 
copy 52.* 

It is apparent from the foregoing passage that conflict checking does not actually occur 
until and unless a user attempts to save his edits7 Therefore, "detecting. . .a modification to 
locally- stored data" can only occur once the user saves his edits. This can occur long after the 
edits were actually made. Such a detection step, which can come hours after an edit has been 
made, cannot reasonably be regarded as detection "in real time." Consequently, Beizer does not 
disclose "detecting at a server, in real-time, a modification to loczilly- stored data occurring at a 
second client[.]" 

Neither Sweat nor Beizer, alone or in combination, disclose or suggest all of the features 
of independent claim 1. Accordingly, a prima facie case of obviousness of claim 1 or of any of 
the associated dependent claims has not been established. Therefore, claim 1 is patentable over 
Sweat and Beizer, alone or in combination. 

Proposed modincation of Sweat changes its principle of operation 

According to MPEP 2143.01(VI) 

"If the proposed modification or combination of the prior art would change the principle 
of operation of the prior art invention being modified, then the teachings of the references 



^ See e.g., Beizer col. 6, lines 17-34. 

^ See also, e.g., Beizer, col. 6 line 64 - col. 7, line 22 ("According to the attended mediation scheme of the present 
invention, the last party to save their WorkFolder will be notified of the conflict when the WorkFolder is saved and 
presented with conflict resolving information, including for example, the two conflicting values of field B and the 
name of the other party to the conflict. In this situation, if user 2 was last to save , a notification would be provided 
that the changes to field B conflicted with data entered b\ I 'ser 1 . I 'ser 2 would then be asked to choose between the 
conflicting data values. It is understood that User 1, as well as third party users, may also be notified of the conflict 
and permitted to participate in the conflict mediation process. In addition, priority may be assigned to users, so that, 
for example. User 2 may be able to override a change made by user 2, but not by user 1. To facilitate this exchange, 
a log of changes to a WorkFolder, including the changed element and the name of the user who made the change, 
may be generated. Preferably, this log is stored in a history "meta-element" associated with the specific 
WorkFolder. Other log elements, such as the time a change was made, the previous value of the field, etc., may also 
be recorded. FIG. 3c illustrates the state of the Master work folder 52, and the local and edited copies 54, 58 of user 
1, both before and after the reconciUation described above when the user 2 changes were saved first. Note that the 
local copy 54 of the updated WorkFolder for user 1 has not been refreshed to reflect the changes from user 2." - 
emphasis added). 
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are not sufficient to render the claims prima facie obvious. In re Ratti, 270 F.2d 810, 123 
USPQ 349 (CCPA 1959)." 

Sweat discloses a system that relies on locking and unlocking files to control 
modification of files by multiple users. 

Beizer's objective was to allow "multiple users to simultaneously access £ind edit the 
same shared data object without requiring an object accessed by one user to be locked relative to 
later users. 

Both Sweat and Beizer are directed to solving the same technical problem, namely 
allowing multiple users to edit the same data. However, one of ordinary skill in the art would 
have seen that the two achieve this objective in different and fundamentally incompatible ways. 

The Examiner notes that Sweal "is silent about identifying conflict."^ But this is because 
when locks are used, only one person at a time can edit a file. Accordingly, no conflict can occur. 
One of ordinary skill in the art would have understood that Sweat "is silent about identifying 
conflict" for the simple reason that locks prevent conflicts. 

In contrast, Beizer specifically eschews the use of locks. As a result, multiple users can 
edit the same data at the same time. This procedure, which is fundamentally different from 
Sweafs, practically invites conflict. It would therefore have come as no surprise to one of 
ordinary skill in the art that Beizer discusses conflict resolution at great length. 

One of ordinary skill in the art would therefore have regarded the proposed modification 
of Sweat to include Beizer's conflict resolution techniques as making no technical sense. One of 
ordinary skill in the art would have recognized that Sweat's use of locks effectively prevents the 
conflicts that would arise in Beizer's lock-less system. 



^ Beizer, col. 2, lines 54-57. 
^ Ojfice Action, page 4, line 22. 
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Accordingly, Applicant submits that the proposed motivation to combine the references is 
flawed, and that the section 103 rejection is therefore improper. 

Claims 30, 31, and 38 include features similar to claim 1 and are patentable for at least 
the same reasons. Claims 3-6, 8, 11-29, 32, 36, and 37 depend from either claim 1 or claim 31 

and are patentable for at least the same reasons. Accordingly, the 103 rejection based on Sweat 
in combination with Beizer is improper and should be withdrawn. 

For at least the foregoing reasons, the applicants respectfully submit that the application 
is in condition for allowzince. 

SECTION 103 REJECTION OF CLAIM 8 

In rejecting claim 8, the Office draws attention to Sweaf^ "activity log," an example of 

which is shown in FIG. 10. As best understood, the Office regards the "activity log" as 
corresponding to claim 8's "audit report." 

Claim 8 requires that the "audit report" include "information corresponding to the real- 
time modification" of "locally-stored data occurring at" the client. The information maintained in 
Sweafs activity log does not include anything connected to modification of locally-stored data. 

SECTION 103 REJECTION OF CLAIM 12 

ApplicEint Eimends cMm 12 to more clezirly define what is mezint by "master rule 

enforcement" as that term is used in the specification. 

Master rule enforcement presupposes the existence of master hierarchical reference data 
and locally- stored hierarchical reference data. This distinction is shown in FIG. 1 of the 
application, which shows master hierarchical reference data 160 at the server 115 and locally 
stored hierarchical reference data 145 at the client 110. 

The cited art, Beizer, describes users modifying their own local copy of a workfolder. 
There is no discussion in Beizer of master rule enforcement that is separate from local rule 
enforcement. 
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Summary 

Any circumstance in which the appUcants have (a) addressed certain comments of the 
examiner does not mean that the appUcants concede other comments of the examiner, (b) made 
arguments for the patentabiUty of some claims does not mean that there are not other good 
reasons for patentabihty of those claims and other claims, or (c) amended or canceled a claim 
does not mean that the applicants concede any of the examiner's positions with respect to that 
claim or other claims. 

Applicant encloses a petition for extension of time and authorization to charge the 
$1,110.00 extension fee to our deposit account. No other fees are believed to be due in 
connection with the filing of this response. However, to the extent additional fees are due, or if a 
refund is forthcoming, please adjust our deposit account 06-1050, referencing attomey docket 
number 08575-0094001. 
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